VideoBrain Video Hardware Patent Overview By Kurt Woloch April 14, 2012 Preface By Adam Trionfo --------------- The VideoBrain's Video Hardware Patent (U.S. patent #4,232,374) is a thick document that needs a translator before the average person can understand it. The obscure abstract of the patent begins thus: A method and apparatus are described for generating, under the control of a microprocessor, signals for operating a scanning system of a standard television receiver. A plurality of display segments, each containing information at least partially defining one or more object images that may be desired be included in a specified display on the receiver, are stored in a cartridge memory which can also include specific operating instructions for carrying out a particular video game or other function with such display segments. Indicia uniquely associated with each of the display segments are placed in a predetermined order correlated with the order of appearance in the display of those display segments which are to be included therein. The position of the scan is tracked, and when it approaches a desired location under the display area for a particular segment to be displayed, it responds to the indicia representing such segment by directing delivery to the scanning system of control signals which define the selected display segment. The apparatus includes composers for producing the display for each line, and a FIFO buffer for delivering information defining the line to the scanning system at a regular rate correlated to the scanning rate, irrespective of the time in which such information is made ready for the display. If you're like me, than the abstract for the patent made absolutely no sense to you. Kurt Woloch wrote a handy overview of the entire patent written in understandable language. Kurt, a member of the Channel F and VideoBrain Yahoo discussion group, shared his concise thoughts with the group. His original message, titled "Hello, or: Videobrain programming" reads as follows: Hi there! I'm Kurt Woloch from Austria. Many of you will probably recognize me from the Ballyalley group and/or from Atariage. Lately I read up some on Videobrain programming. I found this nice patent that essentially goes into great detail how the VB's video hardware works. So I joined this group in order to dig deeper. As far as it seems, there has been no VB homebrew software yet. I've scanned through all the messages here that seem interesting, but so far only Sean Riddle [http://www.seanriddle.com/videobrain.html] seems to have tried any programming, with mixed results. I think that by reading the patent, I understand roughly how the VB video hardware works, how the screens of the existing software are composed and what the limitations of the system are. I don't know that much about sound, however, which isn't mentioned in the patent. I also haven't written anything on the F8 processor so far. Another interesting thing about the patent is that the major part of it is actually a source code listing of the VB's "Tennis" cartridge, so you have an example how to program the VB, at least if you understand F8 programming. What's missing, in my opinion, [are] some videos. I think there are some Videobrain videos out there, but they only show the text-based cartridges, and none of the games. It would be nice to have some videos of the games online in order to check out how they play. I don't think that programming the VB has been discussed in detail on this group, so here are some details I found out by reading the patent: The VB seems to have a similar resolution as the Atari VCS, that's 160 or more pixel columns, and as many pixel rows as there are scanlines. This is also the resolution in which objects can be displayed. The objects are actually called "segments" in the patent. I don't know if you should call them "sprites" instead... The video chip supports displaying 16 objects which have to be strictly rectangular. They can be any height, but the width is restricted to multiples of 8 pixels. All objects can freely move around on screen and even appear on the same scanline if you want, but none of them are allowed to overlap since the data for them is read sequentially and put into a FIFO buffer, filling it up with the background color in places where there's no object. Each object has one of 32 (!) colors (actually, the 8 base colors in one of four intensities) against the global background color. The graphics data for objects can be read from RAM or ROM, however, as I understand it, all data for all objects must come from the same 8K block in memory which disallows data from RAM and ROM being displayed at the same time. The graphics data for each object is laid out sequentially in memory... an object that is two bytes wide, for instance, has the first two bytes contain the graphics for the first scanline (left and right half), the next two bytes for the second scanline (left and right half) and so on. There's also the possibility called XCOPY of having an object being only 1 byte wide, but displayed repeatedly so that it takes up more than 8 pixel columns. There is NO text or indexed mode. Displays appearing this way are actually rendered with heavy CPU usage. If you want to display text, you either have to use one sprite image and copy all the graphics data to it (thereby limiting the data to come from RAM) or put up an individual object for each letter, which then can be read from ROM. In this case, each letter would also be able to have a different color, but the objects have to be re-used in order to display multiple lines of text. There's two "lists" of the 16 allowed objects, list A and B. However, most of the object properties are shared between the two lists, only the Y value (scanline in which the object starts) is allowed to be different. I believe they did this specifically to allow text to be displayed, because it is actually displayed by putting 16 objects (one object per letter) next to each other and then reusing the objects for the next line of text by rewriting some of the properties of the list and switching from List A to B or vice-versa (so they can already update the Y values while the current line of text is still visible).That's probably the reason for the blank space between text lines... because during displaying those scanlines, the CPU re-writes the lists and updates the object properties. You can program line interrupts like on the C-64 which lets the video chip interrupt the CPU when a certain scanline is reached. The object lists have to be sorted by the order in which the objects are appearing on screen... that is, first scanlines first. This requires a constant re-sorting of the lists as objects move up and down. Actually, you could roughly compare this to the "display lists" from the Atari 8-bit/5200 and 7800, or to the copper lists on the Amiga. The VideoBrain video patent can be read here: http://www.orphanedgames.com/videobrain/patents/Videobrain_Patent_4232374/ Videobrain%20Video%20Hardware%20Patent%20%28US%204232374%29.pdf For those interested, the Channel F and VideoBrain group can be visited here: http://tech.groups.yahoo.com/group/channel_f_and_videobrain Visit the group say hello; you're sure to learn something about the incredibly obscure VideoBrain computer system.